What is ACPI?

If you've worked with x86 systems, you've likely heard of ACPI. It's a fundamental standard in modern computing, used in laptops, desktops, workstations, and servers. As the new RISC-V architecture moves into the desktop and server markets, it must inevitably work with ACPI.

ACPI stands for Advanced Configuration and Power Interface. It is an open standard that allows an operating system (OS) to:

• Discover and configure hardware components.
• Automatically configure Plug-and-Play and hot-plug devices.
• Perform power management (e.g., putting the system to sleep).
• Perform status monitoring [1]. The first ACPI specification was published in December 1996, created jointly by Intel, Microsoft, and Toshiba. Over time, more companies joined the effort. Since October 2013, ACPI has been maintained by the UEFI Forum. The latest version, ACPI 6.6, was released in May 2025. Before ACPI, most power management was handled directly by the BIOS. This severely limited what operating systems could do. ACPI replaced older standards like APM (Advanced Power Management), MPS (MultiProcessor Specification), and Legacy Plug and Play BIOS. With ACPI, the OS gains direct control of configuration and power management. This model is called OSPM (Operating System-directed Configuration and Power Management).

ACPI Framework

Here’s how ACPI fits into a system (see diagram):

• Orange area - ACPI Specification (The Rules): This defines the interface between software and hardware.

  • Hardware:
    • ACPI Register Set – A set of registers implemented in hardware, specific to x86. On ARM and RISC-V, a “hardware-reduced” ACPI mode is used, so these registers don’t need to exist.
  • Software: numbers of ACPI Tables are defined and there are two main types:
    • Static Tables (Data Tables): Contain simple data that the OS can read directly.
    • Definition Block Tables: Contain byte code written in AML (ACPI Machine Language). This code must be interpreted by an AML Interpreter inside the OS before it can be understood by ACPI Driver.

• Green area - Operating System Components:

  • ACPI Driver: The OS component that interfaces with ACPI. It contains the AML Interpreter. A well-known open-source project here is ACPICA (ACPI Component Architecture) [3]. ACPICA provides OS-independent ACPI code, including an AML Interpreter, and is used by Linux, FreeBSD, and others.
  • OSPM（Operating System-directed configuration and Power Management）: The overall power management subsystem in the OS, which uses ACPI to make decisions.

• Blue area - Platform/firmware Components:

  • Platform Firmware (BIOS/UEFI): The firmware that starts the machine and implements interfaces for sleep, wake, and reset. It is responsible for generating the ACPI Tables and providing them to the OS.

ACPI Namespace

As mentioned, Definition Block Tables use AML bytecode. The workflow looks like this:

1. Engineers describe hardware in ASL (ACPI Source Language).
2. The ASL compiler (e.g., iASL) compiles this into AML bytecode.
3. The bytecode is packaged into firmware as Definition Block Tables.

At runtime, the OS AML Interpreter parses the AML and builds a tree-like structure of devices, called the ACPI namespace. The OS then queries this namespace to learn about the hardware.

ACPI and UEFI

ACPI often appears alongside UEFI (Unified Extensible Firmware Interface). UEFI is the modern replacement for BIOS.

• Originally proposed by Intel in 1998 as the Intel Boot Initiative, renamed EFI, and finally UEFI in 2005.
• Maintained today by the UEFI Forum [5].
• A major open-source implementation is EDK II from the TianoCore community [6]. While both are specifications, they solve different problems:
• ACPI: Defines how the OS discovers/configures/manages hardware.
• UEFI: Defines the interface between firmware and the OS. Put simply:
• ACPI moved power management out of the BIOS and into the OS.
• UEFI replaced the BIOS itself. Both started with Intel’s involvement, and both are now under the UEFI Forum [7]. They are related but not strictly tied together—bootloaders like U-Boot can use ACPI, and UEFI can work with Device Tree. Still, in the PC/server world, the UEFI + ACPI combo is the dominant and most mature standard.

Why RISC-V Needs to Support ACPI

To understand why RISC-V should support ACPI, we can look at the similar path ARM has traveled: both began in embedded systems, and both now aim to enter the desktop/server space. The challenges ARM faced largely apply to RISC-V too.

Embedded vs. Desktop/Server Ecosystems

ACPI and UEFI are often mentioned together but serve different purposes:

• In embedded systems, a single company often owns and controls the full stack (hardware + firmware + OS). Products tend to be highly customized. For example, with smartphones, end users typically only interact with the final brand—such as Apple, Huawei, or Xiaomi. They cannot easily replace the hardware on the motherboard, and the firmware or operating systems of different phones are usually not interchangeable.
• In the PC/server world, by contrast, involve many different vendors. The CPU, motherboard, power supply, storage, graphics card, and other components can all come from different manufacturers. Users can freely choose parts and assemble a system that meets their needs. Each vendor is only responsible for its own component. Operating systems are also far more portable: a single machine may run Windows, Ubuntu, or other OSes, and the same OS image usually works across a wide variety of hardware. (Of course, there are also highly integrated PCs on the market—such as Apple’s Mac computers or certain laptop models—which resemble smartphones in their closed, embedded-style design. Users cannot easily swap hardware or firmware in these systems. But overall, such products remain a minority in the PC/server ecosystem.) Because so many vendors participate in the PC/server world, with hardware and software expected to interoperate, standards are essential.

The Evolution of the PC/Server Ecosystem Standard

In the 1970s and 1980s, when personal computers (PCs) first entered the market, there were no unified standards. Systems from different vendors were often incompatible. In August 1981, IBM released the IBM PC, and shortly after published almost all of its technical documentation (with the exception of the BIOS). It also allowed third parties to produce compatible hardware, an approach known as open architecture. This move greatly accelerated the growth of the personal computer industry. Over time, the IBM PC became the de facto open standard for personal computers, and machines compatible with it came to be known as IBM PC compatibles [8]. As technology advanced, IBM’s influence over PC architecture declined in the 1990s. Industry leadership shifted toward what became known as “Wintel” [9]—a shorthand for Windows + Intel, referring to PCs based on Intel’s x86 processors running Microsoft’s Windows operating system. Under the guidance of Intel and Microsoft, industry alliances introduced a series of key hardware and software standards such as UEFI, ACPI, and PCI/PCIe. During this period, the term “IBM PC compatible” was gradually replaced by “standard PC” and later “ACPI PC” [8]. The Wintel architecture became—and remains—highly dominant in the x86 world. Its influence extends beyond desktop computers to laptops and servers. Even machines built on x86 processors from other vendors (such as AMD), or running different operating systems (such as Linux), are largely compatible with this architecture.

Device Tree vs ACPI

As mentioned earlier, ACPI uses the ASL language together with the ACPI namespace to describe hardware information for the operating system. In the embedded world, another common approach is Device Tree, which also abstracts hardware details. In terms of pure hardware description, neither ACPI nor Device Tree has an inherent advantage. This raises a natural question: as ARM and RISC-V move into the PC/server domain, could Device Tree follow along and compete with—or even replace—ACPI as a new industry standard? At present, there is no such trend. Compared with ACPI, Device Tree has two key shortcomings in the PC/server ecosystem:

1. Scope of the specification The Device Tree specification [11] focuses mainly on describing hardware using the DTS (Device Tree Source) language. In contrast, the ACPI specification covers much more: besides describing hardware with ASL, it also defines how the operating system interacts with firmware and hardware at runtime. These requirements are essential for ensuring that a single general-purpose operating system can run across different machines.
2. Flexibility ASL is syntactically more powerful than DTS. It supports assignments, flow control, and operators, allowing firmware to implement dynamic behavior without requiring changes to the operating system. For example:

DefinitionBlock ("", "DSDT", 2, "", "", 0x0)
{
    Name (INT1, 0x02)
    Method (CTDW, 1) {
        local0 = arg0
        while (local0) {
            printf ("%o",local0)
            local0--
        }
    }
    
    Method (CTUP, 1) {
        local0 = arg0
        while (local0 < 10) {
            if (!(local0 % 2)) {
                printf ("%o is even", local0)
            } else {
                printf ("%o is odd", local0)
            }
            local0++
        }
    }
}

In short: everything Device Tree can do, ACPI can do as well—and ACPI offers more. Given that ACPI is already the established standard in the PC/server ecosystem, extending Device Tree to cover the same ground (without offering clear advantages) would be both difficult and unrewarding. The natural choice is therefore:

• Use Device Tree in the embedded world, where its lightweight design is a good fit.
• Use ACPI in PCs and servers, where compatibility with the industry ecosystem is critical.

ARM’s Choice

The highly customized nature of embedded products makes it difficult to establish industry-wide standards. When facing the world of personal computers and servers—an ecosystem with decades of history, numerous component vendors, and long-established industry standards—ARM’s commonly used embedded technologies such as U-Boot and Device Tree have little room to gain traction. Naturally, ARM’s choice was clear: in the PC/server, it has fully embraced the standards long used in the x86 ecosystem, such as UEFI, ACPI, and SMBIOS. To this end, ARM introduced the Arm SystemReady standard in 2020, setting requirements for both hardware and software across different products: In the Arm SystemReady Requirements Specification v3.0, released on November 21, 2024 [13], the program's classifications were refined:

• SystemReady LS was deprecated.
• SystemReady ES and SR were consolidated into a new, singular "SystemReady" category. This tier is designed for products capable of running a generic, unmodified operating system and mandates the implementation of ACPI.
• SystemReady IR was renamed to "SystemReady Devicetree," intended for products running embedded Linux/BSD operating systems. Clearly, in the PC/server domain, ACPI plays a critical role. It is an indispensable component for achieving operating system portability and universality.

Hardware-reduced ACPI

ACPI originated in the x86 architecture, and its specification includes a set of hardware registers that are tightly linked to x86 design. However, ARM and RISC-V hardware may not implement these registers. So how can they support ACPI? ACPI Specification v5.0 introduced a new approach called hardware-reduced ACPI, which no longer requires implementing certain ACPI hardware features [14]:

• Power Management (PM) timer
• Real Time Clock (RTC) wake alarm
• System Control Interrupt (SCI)
• Fixed Hardware register set (PMx_* event/control/status registers)
• GPE block registers (GPEx_* event/control/status registers)
• Embedded controller Correspondingly, some functionalities have alternative implementations. For example, the ACPI event notification model on traditional x86 systems is implemented via the SCI （System Control Interrupt）and GPE (General-Purpose Event) registers, where SCI trigger ACPI events. In hardware-reduced ACPI, however, ACPI events can be triggered using either of two mechanisms:

1. GPIO-signaled ACPI Events — ACPI events triggered by GPIO interrupts.
2. Interrupt-signaled ACPI Events — ACPI events triggered by any type of interrupt.

ACPI Power Management

ACPI Power State Categories

The ACPI specification defines the following states for both the system and devices:

• System Global States (Gx) and Sleep States (Sx)
  • G0 (S0) – Working: The normal working state.
  • G1 – Sleeping: Low-power state. From the user’s perspective, the system appears to be off, but it can return to G0/S0 without restarting the operating system. G1 is subdivided into S1–S4 traditional states, plus a newer S0ix state:
    • S1 - Power On Suspend (POS) The least power-saving sleep state. Maintains CPU and memory power while preserving OS context.
    • S2 Deeper sleep than S1 with CPU power removed.
    • S3 - Suspend to RAM (STR)/Standby/Sleep Only memory remains powered. All device contexts except memory contents are lost.
    • S4 - STD (Suspend to Disk) / Hibernation / Non-Volatile Sleep Allows full power-off of the motherboard; OS context saved to non-volatile storage.
    • S0ix Also called Low Power S0 Idle [2], S0ix by Intel [15], Modern Standby by Microsoft [16], or Suspend to Idle (S2Idle) by Linux [17]. Power consumption is close to or lower than S3, and recovery to G0/S0 is faster. S0ix can be further divided into sub-states such as S0i1, S0i2, S0i3.
  • G2 (S5) - Soft Off State Lowest power consumption state. Hardware does not preserve OS context; returning to G0/S0 requires a reboot. Hardware removal may not be safe.
  • G3 - Mechanical Off State Completely powered-off state. No hardware context preserved. OS restart required to return to G0/S0. Only the RTC consumes power.
  • Legacy For systems without ACPI support. Power management is implemented through APM, Legacy PnP, etc.
• Device Power States (Dx) When the system is in G0/S0, devices can switch between the following states (not all devices implement all states):
  • D0 – Fully On: Maximum power, device fully active, all context retained.
  • D1: Device-dependent; generally higher power than D2 with more retained context. Many devices skip this state.
  • D2: Device-dependent; lower power than D1/D0 with less context retained. Many devices skip this state.
  • D3hot: Device-dependent; lowest possible power without affecting device enumeration.
  • D3 (D3cold) – Off: Device completely powered down, all context lost, cannot be enumerated by software.
• Processor Power States (Cx) During active system states (G0/S0), CPUs can enter various power-saving modes:
  • C0: Fully operational, executing instructions.
  • C1 – Halt: Shortest wake latency; CPU does not execute instructions.
  • C2 – Stop Clock: Lower power than C1 but longer wake latency; CPU does not execute instructions.
  • C3 – Sleep: Lower power than C2 with longer wake latency; CPU does not execute instructions.
• Performance States (Px) When CPU or devices are active (C0/D0), they can operate in performance states:
  • P0: Maximum performance and power consumption.
  • P1–Pn: Performance and power decrease as n increases. n is device-dependent, maximum up to 255.

Power Management in Hardware-Reduced ACPI

System-Level Sleep States (Sx)

Traditional x86 ACPI uses hardware registers for Sx state transitions. Hardware-reduced ACPI on ARM/RISC-V generally does not follow x86 methods but defines standardized architecture-level interfaces. They can also use certain UEFI standard interfaces:

• UEFI Runtime Service ResetSystem() allows the OS to perform reboot or shutdown, achieving G0/S0 ↔ G2/S5 transitions. These hardware operations are handled by UEFI/firmware, invisible to the OS.
• ARM defines the SCMI (System Control and Management Interface) standard for power, performance, and system management [18], enabling Sx transitions.
• RISC-V defines the SBI (Supervisor Binary Interface) standard [19], including:
  • SBI SRST (System Reset) Extension for reboot/shutdown.
  • SBI SUSP (System Suspend) Extension for sleep.

Device Power States (Dx)

Device Dx states do not require ACPI hardware registers. Like x86, ARM/RISC-V implement them using ASL objects defined by ACPI. They are as below:

CPU Power States (Cx) and Performance States (Px)

For CPUs, ACPI provides methods to implement Cx and Px states even in hardware-reduced environments:

• LPI (Low Power Idle) States: Combined with the FFH (Functional Fixed Hardware) specification, LPI controls CPU Cx states using architecture-specific methods.
• CPPC (Collaborative Processor Performance Control): Combined with FFH, CPPC controls CPU Px states via coprocessors. Both LPI and CPPC require FFH, which enables ACPI to interface with architecture-specific implementations. x86, ARM, and RISC-V each have their own FFH specifications [20][21][22]. For example, on RISC-V, FFH integrates with SBI extensions:
• Cx states are managed via ACPI LPI States + RISC-V FFH + RISC-V SBI HSM (Hart State Management) Extension.
• Px states are managed via ACPI CPPC + RISC-V FFH + RISC-V SBI CPPC Extension.

RISC-V ACPI–Related Specifications

Learning from ARM’s example, the RISC-V community has long recognized the importance of aligning with ecosystem standards in the personal computer/server domain. As a result, it has actively developed relevant specifications, including those related to ACPI:

• RISC-V BRS (Boot and Runtime Services) Specification [23]: Defines two standards — BRS-I (Interoperable) and BRS-B (Bespoke) — for general-purpose systems and customized systems, respectively. These define software requirements for device discovery, system management, and more, similar to ARM’s SystemReady and SystemReady Devicetree. They also include new definitions and implementation requirements for RISC-V ACPI.

• Enhancements to ACPI Specification for RISC-V Support: Several existing ACPI specifications have been extended to support RISC-V, including:
  • RHCT (RISC-V Hart Capabilities Table): Describes the capabilities of RISC-V Harts (hardware threads).
  • Updates to MADT (Multiple APIC Description Table): Adds structures for describing RISC-V interrupt controllers such as the AIA and PLIC.
• RIMT (RISC-V IO Mapping Table) Specification [24]: Defines the ACPI table specification for describing RISC-V IOMMU (Input/Output Memory Management Unit) information.
• RISC-V FFH (Functional Fixed Hardware) Specification [22]: Defines the ACPI FFH specification for RISC-V, used by the ACPI LPI States and CPPC mechanisms to implement CPU Cx and Px state control.

SpacemiT's Support form ACPI

Currently, SpacemiT’s mass-produced K1 — an 8-core 64-bit RISC-V AI CPU chip — has adapted UEFI based on the open-source Tianocore EDK II [6]. ACPI support is expected to be added in the near future, enabling better adaptation to a more universal and open ecosystem in the terminal field. In addition, SpacemiT is developing a server chip platform based on its self-developed X100 high-performance processor core, which fully supports virtualization, security, RAS (Reliability, Availability, Serviceability), and other server features in compliance with the RISC-V Server SoC Specification v1.0 [25]. This platform has already completed UEFI + ACPI adaptation and can boot the Linux kernel based on ACPI:

Conclusion

RISC-V has grown rapidly thanks to its “openness,” but the “fragmentation” challenge still looms over it. To address this, the RISC-V community has developed various hardware and software specifications and embraced ACPI, inherited from the x86 world, to progressively reduce fragmentation. It is believed that one day soon, RISC-V will achieve the same level of maturity as x86, allowing a single operating system image to run across different machines.